It is becoming more and more important that sensitive data, such as passwords, are kept as hidden as possible. There are a large number of methods of obtaining this data, and it is vital that it is hidden.
There are many environments in which hiding sensitive data is not currently an option. Such environments may include, but are not restricted to, the following:
a. Command lines—Sometimes it is necessary to include a sensitive string within a command line instruction, in which case the item appears in plain text.
b. Parameter files—When a piece of sensitive data needs to be included in a parameter file, then it frequently cannot be encrypted and must appear as plain text.
c. Textual editor—In a text editor, text generally appears in plain format, with little indication as to whether it is sensitive or not.
d. z/OS® data set—Parameters within a z/OS data set may include a piece of sensitive data (z/OS is a trademark of International Business Machines Corporation, registered in many jurisdictions worldwide). Frequently, these are written as plain text, since the editor is unaware that the data is sensitive.
In such environments, it is frequently necessary for information such as passwords to be written in plain text as these environments have no way of knowing that the data they are about to read is sensitive or not.
Currently, many products require passwords to be specified in order to carry out certain commands in command line systems, such as stopping and starting systems. Parameter files are also in common use that contain a list of initialization parameters and a value for each parameter. In both cases, it is common that free text is used for simplicity. This leads to the problem of securing of data within a free text environment.
The security of passwords and other data is often compromised because the parameter files are frequently available to more than one user, and passwords can easily be read. Command lines can be seen by those watching what a user is typing.
There are also particular problems with z/OS data sets, where frequently these data sets are authorized to be read by other users so that configurations can be copied, but the passwords are again in plain text.
The idea of protecting text format of a password in plain text and OS itself is a known prior art, such as Linux or Unix OS and some GUI password field are all password protected. However this disclosure does address a known issue in z/OS and some text editors.
Some methods are known for encrypting sensitive data in plain text environments. One known method makes use of already known parameters that are included as part of a command. For example, anything following a ‘-p’ is a password and should be encrypted. This requires all such entries to be determined by the user in advance.
Other methods include:                Possible encryption methods, which do not address the issue of identifying which text requires encrypting.        The use of textual attributes, which may not be available in all editors.        Manually hiding a specific field, which does not consider a command string.        The passing in of a symmetric key when a data access service is started, which does not consider command lines or the entry of sensitive information within a textual file.        Automatically removing sensitive data from a file, which is not an option when it is required in the future.        
Therefore, there is a need in the art to address the aforementioned problems.